Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type preservation #11

Merged
merged 20 commits into from
Mar 14, 2024
Merged

Type preservation #11

merged 20 commits into from
Mar 14, 2024

Conversation

Aqissiaq
Copy link
Collaborator

Very much a WIP still, with some lemmas I am unsure about the formulation of, but I am a bit stuck and don't want to disappear into a fruitless rabbit hole of substitution properties.

Copy link
Collaborator

@palmskog palmskog left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some high-level comments.

src/abs.ott Outdated Show resolved Hide resolved
src/abs.ott Outdated Show resolved Hide resolved
theories/abs_functional_metatheory.v Outdated Show resolved Hide resolved
theories/abs_functional_metatheory.v Outdated Show resolved Hide resolved
@Aqissiaq Aqissiaq marked this pull request as ready for review March 11, 2024 13:44
@Aqissiaq
Copy link
Collaborator Author

The type preservation proof is closed!

It required a few extra assumptions, in particular

  • A well typed function declaration requires the formal parameters to be distinct
  • The fresh variables in a function call must be disjoint from the formal parameters

Rudi says the former is very reasonable, but the implementation of function calls is so different from these formal semantics that the latter does not correspond directly.

Additionally there are two admits in subst_lemma. Both of these confuse me. There are assumptions in the context that should solve them, but they fail to unify for reasons I do not understand.

@Aqissiaq Aqissiaq requested a review from palmskog March 14, 2024 08:36
Copy link
Collaborator

@palmskog palmskog left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Aqissiaq I think I see what the problem is. The finite maps we are using (FMaps from Stdlib) are not extensional. That is, just because two finite maps m1 and m2 have the same elements, it's not necessarily the case that m1 = m2. Instead Map.Equal asserts something much weaker.

The easiest way to fix this is probably to switch to the extensional finite maps from the Std++ library, which are described here:

Then, your admits would be easy to fix.

Do you think we should do this before or after this PR is merged? Maybe it's easiest to merge this one first?

@palmskog
Copy link
Collaborator

palmskog commented Mar 14, 2024

To give a more complete answer, we could stick to FMap, but then we need to show that the properties are "the same" for two maps that are equal under Map.Equals, i.e., we can replace maps with other maps that have the same key-value mappings and still get the same results. But maybe this is a good opportunity to throw out the very old and semi-maintained FMap anyway.

@Aqissiaq Aqissiaq merged commit 8055c81 into master Mar 14, 2024
4 checks passed
@Aqissiaq
Copy link
Collaborator Author

We should definitely switch to some more ergonomic maps and I have been happy with stdpp.fin_maps elsewhere.

I will merge this one first and consider the type preservation part of #2 done for now, then open a new issue for the maps.

@Aqissiaq Aqissiaq deleted the type-preservation branch March 14, 2024 14:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants